\section{Requirements}

\subsection{Scientific Requirements}

\subsubsection{Component Model Control}
The coupler steers the execution of the components of the CCSM, and coordinates and supports the transfer 
of data between the components.  Each component model is unaware of  the \htmlref{timestep}{glos:tstep} or 
\htmlref{grid}{glos:grid} used by the other
component models, and the component models communicate only through the coupler at a specified communication 
interval. 

\subsubsection{Flexibility} 
The coupler's interfaces to the component models must be well defined, such that existing component models 
can be swapped for new models, or benign substitutes, in a reasonably straightforward manner. 

\subsubsection{Extensibility} 
The coupler must allow the user to modify (add/delete/change) the types and amounts of data which are being 
exchanged between the coupler and the component models, or add a new model to the configuration, with minimal
changes to the coupler code. 

\subsubsection{Time Stepping Method}
\label{timestepping} 
The coupler is required to support either \htmlref{process split}{glos:procsplit} or \htmlref{time split}{glos:timesplit} 
advancement of the component models.  
This requirement is closely associated with the requirement contained in \htmlref{Section}{sequencing}~\ref{sequencing}.

\subsubsection{Computations} 

\begin{itemize}

\item {\bf Fluxes} 
The coupler is required to compute and \htmlref{combine}{glos:combine} interfacial fluxes, as needed, among the various component models. 

\item {\bf Mapping} 
The coupler must perform the necessary \htmlref{mapping}{glos:map} operations required to transform data between different component 
model grids.  Each individual component model is unaware about the grid structures of the other
component models.  When mapping fluxes, conservation must be insured (using the 
\htmladdnormallink{LANL SCRIP package} {http://climate.acl.lanl.gov/software/SCRIP/}
or similar software). 

\item {\bf Merging} 
When data is being prepared for a destination grid, the coupler must be able to \htmlref{merge}{glos:merge} (spatially average) 
data originating from multiple source grids.  For example,  a flux to the atmosphere, within an 
atmospheric grid cell, may be composed of a combination of the flux from the land, sea ice, and ocean models. 

\item {\bf Time-Accumulation and Time-Averaging} 
The coupler must be able to do time accumulation and time averaging of data during the integration for
subsequent distribution to other component models.  This may be necessary for flux conservation when different
models use different communication intervals. 

\item {\bf Diagnostics} 
The coupler must be able to perform and report basic diagnostic calculations, such as spatial and temporal 
averages of the quantities exchanged between component models. 

\end{itemize}

\subsubsection{Grids} 
The coupler is required to support general grid shapes (not just logically rectangular grids).  The coupler must
have the ability to work around \htmlref{masked}{glos:mask} areas. 

\subsubsection{Fault Detection} 
\label{scifaultdetection}
The coupler must perform an initial coherence check to insure that all component models are set-up in the proper
manner for the expected integration.   The coupler must allow periodic coherence checks to assure proper
synchronization.  In situations where the component models fail, the coupler is required to have a mechanism to
detect the failure and shutdown the entire system. 
  
\subsection{Computational Requirements}

\subsubsection{Target Platforms} 
The target platform for the coupler design will be clusters of RISC based multiprocessors.  This architecture is a
superset of traditional one processor per node MPPs (Cray-T3E) and large scalable shared memory systems
(SGI Origin 2000).  Examples of such clusters include the IBM SP and Compaq ES-40 clusters.  Achieving high
performance on both vector and RISC processors is complicated.  Experience has shown that in many
circumstances redundant pieces of code must be generated,  which will necessarily slow the coupler development 
effort.  Therefore, the goal of achieving efficient vector processing performance, 
although desirable, is not a requirement at this time. 

\subsubsection{Language} 
All of the general purpose libraries written for the coupler are required to have a Fortran 90 API or a Fortran 90
module interface.  All physics packages written explicitly for the coupler are required to be written in 
Fortran 90. 

\subsubsection{Parallel Implementation} 
\label{par-impl}
The coupler is required to give the user control in selecting pure message passing, pure shared memory 
multithreading, or \htmlref{hybrid parallel}{glos:hybpar} algorithms to take advantage of different platforms and 
the relative performance of parallel modes on those platforms. 

\subsubsection{Parallel Reproducibility} 
Under certain conditions, bit-for-bit reproducibility is required under the different parallel 
implementations listed in \htmlref{Section}{par-impl}~\ref{par-impl}.  At a minimum the coupler must give bitwise reproducibility 
when a statically loaded executable (same model with identical linked libraries) is rerun on the same machine 
at the same site on the same number of processors.  It is noted that a strict requirement for bitwise parallel 
reproducibility may have a negative impact on performance. 

\subsubsection{Sequencing} 
\label{sequencing}
The coupler functions will support both sequential and concurrent execution of the component models, in a 
fashion such that the user can configure the model/coupler with the sequencing method which makes 
the most sense for a particular problem/platform.  This requirement is closely associated with the requirement 
contained in \htmlref{Section}{timestepping}~\ref{timestepping}. 

\subsubsection{Performance} 
At a minimum the coupler is required to meet or exceed the performance of the current (March 2000) 
\htmladdnormallink{Climate System Model, Version 1.2}{http://www.ccsm.ucar.edu/models/csm1.2.html} and 
\htmladdnormallink{Parallel Climate Model, Version 1.0}{http://www.cgd.ucar.edu/pcm/} when configured 
(component model resolutions and communication intervals) similarly.  That is, for concurrent execution, the 
coupler must at least outperform the most time intensive component model in terms of seconds per model day;  for 
sequential execution, the coupler must not comprise more than 20\% of the entire CCSM execution time.  
It is noted that the user can select a model/coupler configuration which easily can violate this requirement 
(such as configuring a shorter coupling interval requiring more 
mappings and communication). 

\subsubsection{Single Vs. Multiple Executables} 
The coupler is required to accommodate executing in an environment where 
the coupler and the component models comprise a single executable, or 
where the coupler and each component model run as separate executables.  
It is worth noting that single vs. multiple executables is independent of the sequencing method
selected (e.g., concurrent execution can be accomplished with a single executable). 

\subsubsection{Processor Allocation} 
For flexibility, the coupler must be capable of running decomposed into an arbitrary numbers of processors.  This
is transparent to the component models. 

\subsubsection{Communications} 
Only communications between the coupler and the component models are allowed.  Component model to
component model communications are disallowed.  Functionally, n coupler nodes should be able to communicate
in parallel with m model nodes, for an arbitrary (n,m).  Parallel communications between coupler and component
models should be explored, developed and optimized, if possible. 

\subsubsection{Mapping} 
The regridder must be capable of performing arbitrary regriddings; i.e., any mapping from a source grid vector into
a destination grid vector, representable by a transformation matrix, should be supported.  The regridder must be
capable of performing fast, efficient regriddings in parallel either through threading, or message passing, or both. 
The regridder must be able to perform a masked regridding operation. 

\subsubsection{I/O} 
The coupler must be able to read/write restart datasets that insure CCSM bit-for-bit restartability, and write
history datasets consisting of user selected sets and subsets of data being exchanged between the component
models.  If possible, the \htmladdnormallink{NCAR/Unidata I/O Library}{http://www.scd.ucar.edu/css/infrastructure/history} 
will be used. 

\subsubsection{Fault Detection} 
Similar to the scientific functionality requirement in \htmlref{Section}{scifaultdetection}~\ref{scifaultdetection}, the coupler is required to have a 
mechanism which will recognize in a rudimentary fashion that a fatal computational problem has arisen and perform the 
necessary operations to shutdown the entire model system. 
  
\subsection{Imposed Functionality Requirements}

In order to meet the desired requirements of the coupler, it is apparent that the component models will need to
have a priori knowledge of, and must be able to fulfill, some coupler requirements.  A list of possible
requirements of the component models, imposed by the coupler requirements, is given in this section.  Note that
the reverse is also true - the models may impose a requirement of the coupler.   Any requirements of this latter
type are unknown at the present time, but this document recognizes and notes the possibility. 

\subsubsection{Single vs. Multiple Executable} 
The component models are required to make accommodations for system configurations of either a single or
multiple executable running environment.  Furthermore, when the system is configured as concurrently running
component models within a single executable, the component models must have the flexibility to execute within a
designated processor space. 

\subsubsection{Fault Detection} 
The coupler is required to detect and/or react to a system problem, and therefore must receive appropriate fault
detection handshaking signals from the component models.  Thus, the component models are required to provide
such signals.  The component models may also be required to detect a coupler problem and act appropriately. 

\subsubsection{Handshaking} 
Other handshaking requirements between the coupler and the component models include: 

\begin{itemize}
\item interface design 
\item on-command AUTO-restart writing capability 
\item possibly use the CCSM shared code (physical constants, orbital parameters, etc.) 
\item calendar manager 
\end{itemize}

This list is certainly not all-inclusive. 

